home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / software-eng / part1 < prev    next >
Text File  |  1994-04-16  |  14KB  |  330 lines

  1. Newsgroups: comp.software-eng,comp.answers,news.answers
  2. Path: bloom-beacon.mit.edu!hookup!torn!news.ccs.queensu.ca!qucis.queensu.ca!qucis.queensu.ca!dalamb
  3. From: dalamb@qucis.queensu.ca (David Alex Lamb)
  4. Subject: FAQ 1: comp.software-eng questions and answers
  5. Message-ID: <questmsg_766497906@qucis.QueensU.CA>
  6. Followup-To: comp.software-eng
  7. Keywords: FAQ
  8. Sender: dalamb@qucis.queensu.ca (David Lamb)
  9. Supersedes: <questmsg_763477506@qucis.QueensU.CA>
  10. Reply-To: dalamb@qucis.queensu.ca (David Alex Lamb)
  11. Organization: Computing and Information Science, Queen's University at Kingston, Ontario,  K7L 3N6, Canada
  12. References: <faqmsg_766497906@qucis.QueensU.CA>
  13. Date: Sat, 16 Apr 1994 12:05:14 GMT
  14. Approved: news-answers-request@MIT.Edu
  15. Expires: Sat, 4 Jun 1994 12:05:06 GMT
  16. Lines: 311
  17. Xref: bloom-beacon.mit.edu comp.software-eng:11153 comp.answers:4927 news.answers:18127
  18.  
  19. Last-Modified: 30 Nov 1993
  20. Archive-name: software-eng/part1
  21.  
  22. This message gives brief answers to questions that have occurred in
  23. comp.software-eng; in many cases they are also topics many readers would like
  24. NOT to see discussed again soon.  Questions are:
  25.    What's a CASE Tool?
  26.    What's a 'function point'?
  27.    What's the 'spiral model'?
  28.    What is a 'specmark'?
  29.    Where can I find a public-domain tool to compute metrics?
  30.    How do I write good C style?
  31.    What is 'Hungarian Notation'?
  32.    Are lines-of-code (LOC) a useful productivity measure?
  33.    Should software professionals be licenced/certified?
  34.    How do I get in touch with the SEI?
  35.    What is the SEI maturity model?
  36.    Where can I get information on API?
  37.    What's a 'bug'?
  38.    Where can I get copies of standards??
  39.  
  40.  
  41.  
  42. ------------------------------------------------------------------------
  43. Subject: What's a CASE Tool?
  44. Date: 26 Mar 1993
  45.  
  46.  
  47. (see also the archive file "casemsg") (thanks to Scott McGregor
  48. <mcgregor@netcom.com> for inspiring this question)
  49. CASE stands for Computer Aided Software Engineering;  it can be used to mean
  50. any computer-based tool for software planning, development, and evolution.
  51. Various people regularly call the following 'CASE': Structured Analysis (SA),
  52. Structured Design (SD), Editors, Compilers, Debuggers, Edit-Compile-Debug
  53. environments, Code Generators, Documentation Generators, Configuration
  54. Management, Release Management, Project Management, Scheduling, Tracking,
  55. Requirements Tracing, Change Management (CM), Defect Tracking, Structured
  56. Discourse, Documentation editing, Collaboration tools, Access Control,
  57. Integrated Project Support Environments (IPSEs), Intertool message systems,
  58. Reverse Engineering, Metric Analyzers.
  59.  
  60.  
  61. ------------------------------------------------------------------------
  62. Subject: What's a 'function point'?
  63. Date: 31 Jul 1993
  64.  
  65.  
  66. (see also the archive file "funcpoints")
  67.  
  68. Function points and feature points are methods of estimating the "amount of
  69. functionality" required for a program, and are thus used to estimate project
  70. completion time.  The basic idea involves counting inputs, outputs, and other
  71. features of a description of functionality.  If interested, for a fee you can
  72. join:
  73.     International Function Point Users Group
  74.     5008-28 Pine Creek Drive
  75.     Blendonview Office Park
  76.     Westerville, Ohio  43081-4899
  77.  
  78.  
  79. ------------------------------------------------------------------------
  80. Subject: What's the 'spiral model'?
  81. Date: 19 Sep 1991
  82.  
  83.  
  84. (see also the archive file "spiral")
  85. (1)  Barry Boehm, "A Spiral Model of Software Development and Enhancement",
  86.      ACM SIGSOFT Software Engineering Notes, August 1986.
  87. (2)  Barry Boehm "A Spiral Model of Software Development and Enhancement" IEEE
  88.      Computer, vol.21, #5, May 1988, pp 61-72.
  89.  
  90. Basically, the idea is incremental development, using the waterfall model for
  91. each step; it's intended to help manage risks.  Don't define in detail the
  92. entire system at first.  The developers should only define the highest
  93. priority features. Define and implement those.  With this knowledge, they
  94. should then go back to define and implement more features in smaller chunks.
  95.  
  96.  
  97. ------------------------------------------------------------------------
  98. Subject: What is a 'specmark'?
  99. Date: 19 Sep 1991
  100.  
  101.  
  102. (see also the archive file "specmark") The SPECmark is the geometric mean of a
  103. series of benchmarks done by the SPEC group. There are a couple of suites, but
  104. in general SPECmark refers to the results of the first suite.  The suite
  105. includes FORTRAN and C codes, mostly well known codes but slightly hacked
  106. versions.
  107.     SPEC
  108.     c/o NCGA
  109.     2722 Merrilee Drive, Suite 200
  110.     Fairfax, VA 22031
  111.     Phone: (703) 698-9600
  112.     FAX:   (703) 560-2752
  113.  
  114.  
  115. ------------------------------------------------------------------------
  116. Subject: Where can I find a public-domain tool to compute metrics?
  117. Date: 17 Jan 1992
  118.  
  119.  
  120. (see also the archive file "static") Volume 20 of newsgroup comp.sources.unix
  121. contained a public-domain package called "metrics", which computes McCabe and
  122. Halstead metrics.  There are many comp.sources.unix archives around the net.
  123.  
  124.  
  125. ------------------------------------------------------------------------
  126. Subject: How do I write good C style?
  127. Date: 19 Sep 1991
  128.  
  129.  
  130. This is answered regularly in the comp.lang.c FAQ.  Try "Recommended C style
  131. and Coding Standards", on host archive.cis.ohio-state.edu (128.146.8.52) via
  132. anonymous ftp in directory pub/style-guide.
  133.  
  134.  
  135. ------------------------------------------------------------------------
  136. Subject: What is 'Hungarian Notation'?
  137. Date: 19 Sep 1991
  138.  
  139.  
  140. (see also the archive file "hungarian") A naming convention for C code.  See
  141. Charles Simonyi and Martin Heller, "The Hungarian Revolution", BYTE, Aug. 1991
  142. (vol. 16, no. 8).  There are other naming conventions;  see, e.g.  "A Guide to
  143. Natural Naming", Daniel Keller, ETH, Projekt-Zentrum IDA, CH-8092 Zurich,
  144. Switzerland. Published in SIGPLAN Notices, Vol. 25, No. 5, pages 95-102.
  145.  
  146.  
  147. ------------------------------------------------------------------------
  148. Subject: Are lines-of-code (LOC) a useful productivity measure?
  149. Date: 26 Jan 1993
  150.  
  151.  
  152. (see also the archive file "static") Not unless you are very careful.  Capers
  153. Jones' book has a detailed and insightful discussion of Lines of Code,
  154. including anomalies, and shows how to use it sensibly (eg in a single job
  155. shop, with a single language, and a standard company coding style).  It is
  156. easy to cook up anomalies where LOC gives different numbers for code written
  157. in different styles, but pathological cases should get caught in code
  158. inspections.  References:
  159. -    T. Capers Jones, Programming Productivity, McGraw-Hill, New York, 1986
  160. -    Capers Jones, Applied Software Measurement: Assuring Productivity and
  161.      Quality, McGraw-Hill, Inc., 1991, 494 pages ISBN 0-07-032813-7
  162.  
  163. The appendices of the latter give rules for counting procedural source code,
  164. as well as rules for counting function points and feature points.  The
  165. following study, cited in Boehm's _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g _E_c_o_n_o_m_i_c_s, claims that
  166. anomalies that seriously "fool" the LOC metric show up rarely in real code.
  167. -    R. Nelson _S_o_f_t_w_a_r_e _D_a_t_e _C_o_l_l_e_c_t_i_o_n _a_n_d _A_n_a_l_y_s_i_s _a_t _R_A_D_C, Rome Air
  168.      Development Center, Rome, NY.  1978.
  169.  
  170.  
  171. ------------------------------------------------------------------------
  172. Subject: Should software professionals be licenced/certified?
  173. Date: 19 Sep 1991
  174.  
  175.  
  176. This is a very controversial and political question.  Generally, certification
  177. is something voluntary, while licencing is regulated by governments.
  178. Certification generally means some agency warrants you meet its standards;
  179. licencing generally means that to claim to practice a certain profession
  180. requires a government licence, often administered through a professional
  181. organization.  In theory both are supposed to help judge if someone is capable
  182. of doing certain jobs.
  183.  
  184. Licencing isn't currently required for computing professionals;  some people
  185. would like to see some jobs require it, as with established branches of
  186. engineering.  Others don't like government intervention, and/or believe many
  187. people who wouldn't get licenced are perfectly competent.
  188.  
  189. Computing professionals in the USA have had a certification program for years,
  190. administered by the Institute for Certification of Computer Professionals
  191. (708-299-4227), a meta-organization with representatives from ACM, IEEE-CS,
  192. ADAPSO, ICCA, IACE, AIM, DPMA, AISP, COMMON, ASM, CIPS, and AWC.  There are
  193. three certificates aimed at different broad types of practitioner, and many
  194. areas of specialization.  To keep a certificate requires at least 40 hours of
  195. continuing education each year; credit can also be obtained for self-study,
  196. teaching, publication, etc.
  197.  
  198.  
  199. ------------------------------------------------------------------------
  200. Subject: How do I get in touch with the SEI?
  201. Date: 29 Nov 1993
  202.  
  203.  
  204. For general information about the SEI, contact the customer relations
  205. department of the Software Engineering Institute at:
  206.     internet:  customer-relations@sei.cmu.edu
  207.     Phone:  (412) 268-5800
  208. A subscriber service is available to U.S. mailing addresses. Subscribers
  209. receive the SEI quarterly newsletter, Bridge; invitations to SEI public
  210. events; and first notification of course offerings and new publications.  To
  211. become a subscriber, contact Customer Relations.
  212.  
  213. To order an SEI publication, contact NTIS, DTIC, or RAI directly:
  214.     National Technical Information Service (NTIS)
  215.     U.S. Department of Commerce
  216.     Springfield, VA 22161-2103
  217.     Telephone: (703) 487-4600
  218.  
  219.     Defense Technical Information Center (DTIC)
  220.     ATTN: FDRA Cameron Station
  221.     Alexandria, VA 22304-6145
  222.     Telephone: (703) 274-7633
  223.  
  224.     Research Access Inc. (RAI)
  225.     3400 Forbes Avenue
  226.     Suite 302
  227.     Pittsburgh, PA 15213
  228.     Telephone: (412) 682-6530
  229.     FAX: (412) 682-6530
  230.  
  231.  
  232. ------------------------------------------------------------------------
  233. Subject: What is the SEI maturity model?
  234. Date: 31 Jan 1992
  235. Originally-From: mcp@sei.cmu.edu (Mark Paulk)
  236.  
  237.  
  238. (see also the archive file "maturity")
  239.  
  240. Maturity is not an easy concept to get down to a single paragraph, but
  241. consider this.
  242.  
  243. Premise:  The quality of a software system is largely governed by the quality
  244. of the process used to develop and maintain the software.  Basics:  The first
  245. step in improving the existing situation is to get management buy-in and
  246. management action to clean up the software management processes (walk the
  247. talk, as TQMers frequently say).  Integration:  The second step is to get
  248. everyone working together as a team.  Measurement:  The third step is to
  249. establish objective ways of understanding status and predict where things are
  250. going in your process.  Continuous improvement:  Understand that this is
  251. building a foundation for continually getting better.
  252.  
  253.  
  254. ------------------------------------------------------------------------
  255. Subject: Where can I get information on API?
  256. Date: 14 Feb 1992
  257.  
  258.  
  259.  
  260. API stands for Application Programming Interface.  For general information on
  261. API standards, you can look at NIST Spec. Pub.  500-187, "Application
  262. Portability Profile." (contact Barbara Blickenstaff, 301-975-2816). Many of
  263. the open systems APIs are being developed in the IEEE POSIX groups.  An
  264. article in the Dec. 1991 IEEE Spectrum describes these and related API
  265. standards. IEEE standards aren't distributed electronically, but both of the
  266. documents above tell how to obtain copies.
  267.  
  268.  
  269. ------------------------------------------------------------------------
  270. Subject: What's a 'bug'?
  271. Date: 12 May 1992
  272.  
  273.  
  274.  
  275. You can take your pick:
  276. (1)  Don't use "bug", use "fault" (an incorrect instruction or definition),
  277.      "failure" (an incorrect result), or "mistake" (a human action leading to
  278.      a failure).  Paraphrased from
  279.          IEEE Standard Computer Dictionary
  280.          Standard 610, ISBN 1-55937-079-3
  281.          Institute of Electrical and Electronic Engineers, Inc.
  282.          345 East 47th Street
  283.          New York, NY 10017-2394  USA
  284.          $49.50 (US$) for IEEE members
  285. (2)  Beizer, in a footnote on page 33 of the second edition of _S_o_f_t_w_a_r_e
  286.      _T_e_s_t_i_n_g _T_e_c_h_n_i_q_u_e_s says (paraphrased):
  287.          I'm sticking with "bug" because everyone  knows  what  it  means,
  288.          there  are  several  "standards"  for other terms that are incon-
  289.          sistent with each other, the OED says that the conventional  com-
  290.          puter  meaning  of  "bug" is ancient, and short Anglo-Saxon words
  291.          are preferable to long Norman ones.
  292.  
  293.  
  294. ------------------------------------------------------------------------
  295. Subject: Where can I get copies of standards??
  296. Date: 26 Jan 1993
  297.  
  298.  
  299.  
  300. ISO, ANSI, and IEEE standards are usually sold to raise some of the funds
  301. that the various national and international standards bodies (who usually
  302. own the copyright) need to keep afloat; thus they are not normally avail-
  303. able electronically.  Also, the organizations are concerned that electron-
  304. ic copies would make it too easy for people to disseminate doctored ver-
  305. sions of the standards.
  306.  
  307. ISO standards may be purchased from:
  308. In Canada:
  309.     Standards Council of Canada / Conseil canadien des normes
  310.     1200-45 O'Connor,
  311.     Ottawa K1P 6N7
  312.     Phone: (613) 238-3222
  313.     Fax:   (613) 995-4564
  314. On CD-ROM:
  315.     Omnicom, Inc.
  316.     115 Park St. SE
  317.     Vienna, VA 22180-4607
  318.     1-800-OMNICOM
  319.     Also available through the National Technical Information Service
  320.     (NTIS), 5284 Port Royal Rd., Springfield, VA 22161, (703)
  321.     487-4650.
  322.  
  323. There were once some CCITT standards on-line at the University of Colorado,
  324. but the arrangement to make them available via the Internet was terminated at
  325. the end of 1991.
  326. -- 
  327. Software Technology Laboratory      dalamb@qucis.queensu.ca (David Alex Lamb)
  328. Computing and Information Science   phone: (613) 545-6067
  329. Queen's University, Kingston, Ontario, Canada K7L 3N6    
  330.